SPEC-PRD-PRO · v0.5
27 June 2026
Owner: Platform team

Products — product requirements

A RiverSync device is one model in a product family, and the model determines the shape of the telemetry the device emits. This PRD makes device → product → telemetry structure an explicit, catalogued chain — and, for the nevera line, extends it to a configure-to-order reality: a unit is a chassis populated with modules under compatibility and capacity rules, and its configuration grows over its life. It consolidates the product-and-telemetry-taxonomy requirements that span Pipeline (quote lines), Portal & Field (devices) and the Devices domain.

1The chain in one paragraph

RiverSync products are organized into families (each with a product class), and each family holds one or more models. The model is a catalog entity — every device and every quote line references it, so a device's product identity is unambiguous. The frigo and koelkast lines are fixed-configuration models. The nevera line is different: a model names only the chassis (30U or 40U form factor), and each unit is configured from a catalog of controller and cooling modules under compatibility and capacity rules — so a device records its installed module loadout, not just a model, and that loadout grows over the unit's life. Separately, the fleet emits telemetry in several distinct shapes; the platform keeps a telemetry-schema registry, every model declares the schema family it speaks, and each device is classified to exactly one schema family + version as ground truth. The data model names these ProductFamily · ProductModel · TelemetrySchemaFamily · DeviceSchemaAssignment, owned by the Devices service (SVC-DVC).

2One product, several surfaces

The product model is curated in the catalog, configured and sold on a quote, attached to a device at provisioning, read on the device, expanded in the field, and resolved to a telemetry schema by classification. Each app touches the same catalog and the same configuration rules.

App	What it does with the product
Admin	Curates the catalog — families, classes, models, the module catalog and its configuration rules, and the telemetry-schema registry are RiverSync-managed reference data (PRO-1/2/3, PRO-8/9, LIF-4)
Pipeline	Sold as a configured quote — a nevera line is a chassis plus a valid module loadout, each item referencing a catalog SKU, never free text (PRO-2, PRO-7); rules are enforced before a quote can be issued (PRO-9)
Portal	The device reads its model + class and its installed loadout; capacity headroom and telemetry render in the shape its classified schema declares (PRO-4, PRO-10/11)
Field	The engineer sees the device's model and loadout on a visit, and adds or swaps modules as demand grows (the pay-as-you-grow visit); classification needs-review surfaces to RiverSync users (PRO-5, PRO-10)

3The edge micro data center lines — frigo & koelkast

frigo (“refrigerator”, Italian/Spanish) and koelkast (“refrigerator”, Dutch) are RiverSync's two edge micro data center lines — the established, fixed-configuration counterpoint to nevera. Each is a single sealed enclosure with a fixed cooling capacity set by its model: there is no module bay, no controller/cooling catalog and no field expansion. The two families share the edge class and the same capacity points; what distinguishes them is the compressor: frigo uses a fixed-speed screw compressor, koelkast uses an inverter variable-speed compressor that modulates cooling to load. Each line ships in two models — 20 and 30, where the number is the usable rack height (20U / 30U) with its paired capacity.

Only the 2nd-generation models are supported on the online platform (PRO-16): Frigo 20 / 30 and Koelkast 20 / 30. The 1st-generation capacity-named units (frigo 2500 / 3500, koelkast 4500 / 5500) are legacy and are not supported here — they do not onboard, classify or appear in the sellable catalog. No datasheet was provided for the 2nd-generation lines — spec-pending cells await one.

Model	Frigo 20	Frigo 30	Koelkast 20	Koelkast 30
Family	frigo	frigo	koelkast	koelkast
Generation	2nd generation — supported on the platform
Class	edge micro data center · fixed configuration
Compressor	fixed-speed screw		inverter variable-speed
Cooling capacity	2,500 W	3,500 W	2,500 W	3,500 W
Usable rack	20U	30U	20U	30U
Configuration	sealed, single-capacity — no module loadout, no field expansion
Controllers	single integrated controller per unit (contrast nevera multi-controller)
Telemetry schema	refrigeration family (the established 60-field shape)
Dimensions · weight · power	— spec pending (datasheet)

Frigo and Koelkast are capacity-paired — a 20 is 2,500 W / 20U and a 30 is 3,500 W / 30U in either family — so the choice between the lines is driven by the compressor behaviour (fixed-speed screw vs. load-modulating inverter), not by capacity. Because the configuration is fixed, a device record needs only its model + serial — no module loadout, no capacity-headroom tracking, no expansion visits. This is the simplification that makes the modular nevera record (§6, PRO-7…11) the exception rather than the rule, and it keeps the established fleet cheap to model.

4The nevera modular platform

nevera ("refrigerator" in Catalan) is RiverSync's modular micro data center line. Unlike the fixed frigo / koelkast units, a nevera is a scale-up platform: it ships with a base cooling module and expands in the field as IT heat load grows — "pay as you grow", no need to invest up front for future capacity. The catalog must therefore model, beneath the model, a configurable product: a chassis, a module catalog, and the rules that bind them.

Two model axes only — the chassis form factor (30U / 40U usable rack). Everything else is configuration. Source: nevera datasheet v3.0 (2025-06-30); the system cooling maxima are the RiverSync-confirmed figures — 5,000 W (nevera-30) / 7,500 W (nevera-40), which supersede the datasheet spec-sheet table.

Chassis envelope	nevera-30 (30U)	nevera-40 (40U)
Form factor	19″ rack · 30U usable	19″ rack · 40U usable
Cooling capacity — base	2,500 W	2,500 W
Cooling capacity — max	5,000 W	7,500 W
Redundancy class	N+1	N+2
Max cooling modules	2	3
Max inverter modules	2	2
Drainage	Evaporative	Dry-up
Airflow · control · cloud	Front-back · touch screen · customer portal	Front-back · touch screen · customer portal
Dimensions (W×D×H)	785 × 1580 × 1600 mm	785 × 1580 × 2050 mm
Weight — empty / full	240 / 320 kg	300 / 420 kg

Every cooling module carries its own controller; one master controller (CM1V) synchronizes the slave controllers so the system actively balances cooling to live demand. A unit is therefore valid only as a set of modules within the chassis envelope — the module catalog & configuration rules below are what make a quote or a provisioning record legitimate.

§4 nevera modular platform · continued

Module catalog & configuration rules — nevera only

This subsection applies to the modular nevera platform only. frigo and koelkast (§3) are fixed-configuration and have no modules. Two module kinds, each a serial-tracked, priced catalog entity. SKU codes (CM1V, 2500V, …) are manufacturer identifiers — retained verbatim, not contractions to expand.

Controller modules

SKU	Role	Compressors	Rack	Weight
CM1V	Master	1× inverter	30U or 40U	15.2 kg
CS1V	Slave	1× inverter	30U or 40U	11.2 kg
CS1F	Slave	1× fixed	30U or 40U	4 kg
CS2F	Slave	2× fixed	40U only	8 kg
CSVF	Slave	1× inverter + 1× fixed	40U only	15.2 kg

Cooling modules

SKU	Compressor	Capacity	Coils E / C	Max power	Weight
3500V	Inverter	3,500 W · 12,000 BTU	6R / 2R	1,725 W	35 kg
2500V	Inverter	2,500 W · 9,000 BTU	6R / 2R	1,204 W	33 kg
3500F	Fixed	3,500 W · 12,000 BTU	6R / 2R	1,656 W	41 kg
2500F	Fixed	2,500 W · 9,000 BTU	6R / 2R	1,154 W	39 kg
2000F	Fixed	2,000 W · 7,000 BTU	4R / 1R	751 W	37 kg
1500F	Fixed	1,500 W · 5,000 BTU	4R / 1R	581 W	37 kg

All cooling modules: R134 refrigerant; shared module bay 425 × 307 × 89 mm. "V" = inverter compressor, "F" = fixed.

Configuration tiers (what each chassis ships and accepts)

Slot	Tier	nevera-30 (30U)	nevera-40 (40U)
Controller	Included	CM1V	CM1V
	Optional	CS1V · CS1F	CS1V · CS1F · CS2F · CSVF
Cooling	Included	2500V	2500V
	Upgrade	3500V	3500V
	Optional	2500V · 3500V · 2500F · 2000F · 1500F	2500V · 3500V · 2500F · 2000F · 1500F

5Requirements

6Model impact — alignment to do

PRO-7…11 introduce configurability that the current data model does not yet carry. Flagged here so the ERD / domain cascade is explicit; proposed entities below await their catalog turn.

Where	Change needed
ERD SPEC-ERD-PRO	New entities: ProductModule (catalog SKU, kind = controller \| cooling, attributes) · ConfigurationRule (per-chassis ceilings, redundancy, rack constraints) · DeviceModuleLoadout (the installed-module records on a Device, serial-tracked, time-bounded for swaps). Relate ProductModel (chassis) → allowed modules; add capacity-headroom derivation. ⚠ pending
Domain SVC-DVC	Devices service owns the module catalog and loadout; /products exposes modules + rules; a loadout change emits a past-tense event (device.loadout-changed) the audit trail consumes. ⚠ pending
Pipeline SPEC-APP-PIP	A quote line for nevera is a configured line (chassis + modules) validated against PRO-9 before issue; expansion quotes reference an existing device's loadout (PRO-10).
Field SPEC-APP-FLD	The pay-as-you-grow install/expansion visit records loadout changes against the device (PRO-10).

7Open questions

• 1st-generation devices in demo data. The Field app demo data (apps/field/field-data.js) still lists 1st-generation capacity-named units (frigo 2500 / 3500, koelkast 4500 / 5500) with FIL-35 / FIL-55 filters. Per PRO-16 these are unsupported on the platform — refresh the demo fleet to 2nd-generation Frigo / Koelkast 20 / 30. ⚠ (PRO-16)
• 2nd-generation datasheets. No spec sheet was provided for the supported lines, so dimensions, weight, power draw, airflow and refrigerant are spec-pending (§3). Obtain them to bring the envelope to nevera parity. (PRO-12)
• Legacy cutover. How are existing 1st-generation units handled at onboarding — hard-rejected, or shown as “unsupported, upgrade required”? And is there a trade-in / replacement path to a 2nd-generation model? (PRO-16)
• Inverter telemetry fields. Does koelkast's variable-speed modulation need named refrigeration-schema fields (compressor Hz / duty) that frigo leaves null, or is it captured in existing fields? Confirm before the registry encodes it. (PRO-14)
• System max vs module sum. The confirmed system maxima (5,000 W / 7,500 W) sit below the arithmetic sum of the largest cooling modules (e.g. 3 × 3,500 W on a 40U); the capacity envelope (PRO-9) is the binding cap. Confirm how the 3,500 W modules are limited in a full multi-module config — derated, count-capped, or simply not combinable to the theoretical max. ⚠ (PRO-9)
• Module entities — when does the ERD cascade land? PRO-7…11 are stated as requirements but the catalog still models only ProductModel. Schedule the SPEC-ERD-PRO / SVC-DVC change (§6) — until then a nevera's loadout is requirement-only, not modeled. ⚠ (PRO-7, PRO-8)
• Configured-quote authority. Are module SKUs and configuration rules curated solely in Admin, or can a Pipeline deal propose a not-yet-catalogued combination for RiverSync to confirm? (PRO-9)
• Loadout history granularity. Does Portal need the full module-swap timeline per device (each add/swap, by whom, on which visit), or only the current loadout + capacity headroom? (PRO-10)
• Class beyond the three lines. frigo · koelkast · nevera are the lines today; does the class need to be an open catalog for future product lines, or a fixed enum?
• Schema discovery loop. When the quarantine bucket reveals a new repeating shape, who promotes it to a registered family — an automatic proposal to needs-review, or a manual Admin action? (PRO-5)
• Telemetry retention. What is the per-family retention horizon for the time-series store, and is it tier- or tenant-configurable? (PRO-6, PTL-1 ⚠)

8Revision history

Version	Date	Changes
0.1	27 Jun 2026	First draft — consolidates the product & telemetry-taxonomy requirements (PRO-1…6) from master SPEC-PRD §6 into their own cross-cutting PRD, alongside Federation and Maintenance.
0.5	27 Jun 2026	nevera confirmed cooling maxima. System cooling max set to the RiverSync-confirmed figures — nevera-30 5,000 W (30U usable) · nevera-40 7,500 W (40U usable) — superseding the datasheet spec-sheet table (7,000 / 10,500 W); resolves the v0.2 spec-sheet-vs-marketing open question. Chassis table, PRO-9 capacity envelope and §4 source note updated; new open question logs the system-max-vs-module-sum reconciliation. Master §6 in lockstep (SPEC-PRD v0.31).
0.4	27 Jun 2026	Generation correction — frigo & koelkast 2nd-gen model (PRO-13/14/15 revised, PRO-16 added). The supported models are the 2nd-generation Frigo 20 / 30 and Koelkast 20 / 30 (number = usable rack U: 20U·2,500 W, 30U·3,500 W); the family axis is the compressor (frigo fixed-speed screw · koelkast inverter variable-speed), not a capacity band. The 1st-generation capacity-named units (2500/3500/4500/5500) are legacy & unsupported online (PRO-16). Reverts the v0.3 capacity-naming; restores Frigo/Koelkast 20/30 as canonical across PRO-2 and the ERD catalog. Field demo-data refresh logged §8. Master §6 updated in lockstep (SPEC-PRD v0.30).
0.3	27 Jun 2026	frigo & koelkast documented (PRO-12…15). Added §3 the edge micro data center lines — both fixed-configuration sealed enclosures, capacity-named models (frigo 2500 / 3500, koelkast 4500 / 5500), refrigeration schema, model-banded service. PRO-2 amended to capacity naming; the legacy -20 / -30 codes are superseded (reconciliation logged §8). No datasheet for these lines — envelope cells marked spec-pending. Master §6 updated in lockstep (SPEC-PRD v0.29).
0.2	27 Jun 2026	nevera modular product model (PRO-7…11), from datasheet v3.0. Adds §3 the nevera modular platform (chassis envelope), §4 module catalog (5 controller + 6 cooling SKUs) & configuration rules, and §6 model-impact / ERD-domain cascade. PRO-2 amended — nevera model = chassis form factor; configuration sits beneath it. Master §6 updated in lockstep (SPEC-PRD v0.28); the SPEC-ERD-PRO / SVC-DVC module-entity cascade is logged ⚠ pending. Flagged the spec-sheet vs marketing capacity discrepancy.